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ABSTRACT 

The exchange of Computer Aided Design (CAD) information between dissimilar CAD systems 
is a problem. This is especially true for transferring electronics CAD information such as multi-chip 
module (MCM), hybrid microcircuit assembly (HMA), and printed circuit board (PCB) designs. 
Currently, there exists several neutral data formats for transferring electronics CAD information. 
These include IGES, EDIF, and DXF formats. All these formats have limitations for use in 
exchanging electronic data. In an attempt to overcome these limitations, the Navy’s MicroCIM 
program implemented a project to transfer hybrid microcircuit design information between 
dissimilar CAD systems. The IGES (Initial Graphics Exchange Specification) format is used since 
it is well established within the CAD industry. The goal of the project is to have a complete 
transfer of microelectronic CAD information, using IGES, without any data loss. An Application 
Protocol (AP) is being developed to specify how hybrid microcircuit CAD information will be 
represented by IGES entity constructs. The AP defines which IGES data items are appropriate for 
describing HMA geometry, connectivity, and processing as well as HMA material characteristics. 

INTRODUCTION 

There exists today within the Microelectronics industry a variety of established ECAD (Electronic 
Computer Aided Design) systems. These systems all have their own proprietary formats for 
representing ECAD information. To communicate with another ECAD system, design information 
must be converted to a neutral format. The data is then transferred to the other system which in turn 
translates the information from the neutral format to its own proprietary format, figure 1. This 
process is executed everyday within an engineering company, a company’s engineering department, 
between a design organization and a manufacturing organization, and between a customer and a 
fabricator. Unfortunately, this process is not robust, numerous errors occur during the translation 
portion of the processes. Errors are often in the category of missing, incomplete, or extraneous 
information, see Table 1. Asa result, the design file received into the receiving CAD system must 
often be edited or updated. The update process consist of returning the file into a robust state. The 
goal is to have the transferred file be equal (functionally and informationally) to the original file. 
This can often be a very tedious, expensive and time consuming process for larger CAD files 
depending upon the extent of repair to be done. 

Table 1 

Typical Transfer Problems Using IGES 


1. Loss of information on different layers. 

2. Loss of dimensional intelligence. 

3. Alteration of text and line fonts. 

4. Loss of non-geographical information. 

5. Loss of connectivity information 

6. Loss of components configuration info. 

7. Loss of routing information. 
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The U.S. Navy must often bear the final cost of the problems its manufacturers/suppliers have 
in transferring CAD information. For this reason, the U.S. Navy, through its MicroCIM project office 
at NCCOSC RDT & E Division, decided to investigate this problem. The MicroCIM program was 
charged with working with the military hybrid microcircuit assembly (HMA) industry to 
implement/develop new technology. One such technology is the errorless transfer of hybrid 
microcircuit ECAD information between dissimilar CAD systems. A method for achieving this 
exchange using an established neutral format has been developed. The neutral format chosen is IGES 
(Initial Graphic Exchange Specification) for reasons which will be discussed later. The method was 
put in the form of an Application Protocol (AP), so called because the method is a protocol for 
applying IGES in the successful transfer of CAD information. The AP is intended to be used by 
manufacturers of ECAD systems and software when building their next generation systems[l]. The 
AP details to the manufacturer how to represent hybrid design constructs in the IGES format. It 
standardizes the IGES representation of a hybrid microcircuit assembly CAD file. This standardized 
method of representing HMA design file entities will allow the errorless transfer of HMA ECAD files. 
Referring to Table 1 it is seen that the majority of errors are rooted in the lack of standardization in 
the representation of HMA ECAD file constructs when using neutral formats. 

The remainder of this paper will present some background information and then explain the AP, 
how it was developed, and how it can be used. 

BACKGROUND 

HMAs 

The focus of the AP is on the electronic information necessary to fully represent hybrid 
microcircuit assemblies. Generally, HMAs are non-monolithic integrated circuits, made up of two 
or more different technologies, and may consist of semiconductor chips and capacitors attached to 
a ceramic substrate with printed resistors and interconnections! 1], This is the basic definition which 
is used in the AP. This definition is meant to be inclusive of Multi-chip Modules, thick film HMAs, 
thin film HMAs, and low temperature co-fired ceramic (LTCC) HMAs. 

IGES 

As stated earlier, IGES is a neutral format specification for describing electronic information such 
as CAD files. IGES is an acronym for Initial Graphics Exchange Specification. It is a specification 
which had it first release in the early 80s. The purpose of the standard is to provide a means by 
which to represent and communicate product definition data in a digital format. IGES has grown to 
be inclusive of almost all types of production definition data, especially CAD/CAM information. 
This data can be in the form of engineering drawings, documentation, 2D & 3D designs, and solid 
models. 

In the ECAD world there are several existing neutral file specifications for various areas of 
electronic information! 1 ]. Two such specifications used in the analysis and hardware areas 
respectively are EDIF (Electronic Design Interchange Format) and VHDL (VHSIC Hardware Design 
Language). IGES was chosen over EDIF and VHDL for implementation in the AP for several reasons; 
l)It is a standard format available in the majority of CAD systems, ECAD, drafting, or other, 2)It 
is widely used in industries for transferring design file between machines, 3)IGES is a very flexible 
language with multiple ways to define entities, and 4)It can readily represent information within the 
scope of the AP. 

To put ECAD information into an IGES format a translator is required. The translator operates 
by mapping information contained in a proprietary ECAD database into the IGES format[2]. The 
mapping can be in either binary or ASCII where the ASCII generates a readable IGES file. The IGES 
file structure contains five distinct sections. The Start Section contains 72 columns of human readable 
comments which are not processed by the program. The second section is the Global Section which 
is a free format area specifying the information needed by the pre-processor and information needed 
by post processor to manage a file. The Directory Entry (DE) section and Parameter Data (PD) 
sections are usually the largest sections in the IGES file. The DE section contains the descriptive 


attribute data for each entity used in the original file. The Parameter Data (PD) section follows, and 
it contains entity definition and actual parameters for each of the entities in the DE section. The last 
section in an IGES file is the terminate section which contains a single record that has the count of 
the records in each previous section. The IGES version 5.0 manual has more detailed information 
about this as well as detailed information on current entities supported by IGES. 

APPLICATION PROTOCOL (AP) 

An AP, in its most generic form, is a protocol for applying some type of information or 
technology! 1]. In our case, we describe how to apply the IGES neutral data format for representing 
HMA ECAD information. This AP develops a standard representation for HMAs so as to minimize 
cost, maximize efficiency in the design process, and provide a means for handling the increasing 
complexity of HMAs[2]. The procedure used in this AP (and similar APs) involves identifying the 
information required to fully describe an application area (HMAs) and representing that information 
in the form of a conceptual model. This model is then used to select the appropriate IGES constructs 
for representing the information. 

Our AP is centered around three models: AAM, AIM, ARM. The AAM, Application Activity 
Model, presents the generic activities needed to design and fabricate HMAs. The ARM, Application 
Reference Model, represents the information needed to support the AAM activities or the information 
generated from those activities. The physical location of the information contained in the ARM can 
be found in the AAM. The AIM, Application Interpreted Model, specifies the constructs of a 
standard, such as IGES, for use in transferring some to all the information described in the ARM. 
Together, these models define the appropriateness of IGES constructs for describing the geometry of 
the various parts of a hybrid microcircuit, its inner connectivity, and processing and material 
characteristics. 

The scope of the AP is to support design, fabrication, and final assembly information for an 
HMAfl]. The AP does not support all information required for electrical testing of HMAs. The 
information contained in the ARM limits the AP scope to layered electrical products information 
which is currently contained in ECAD systems. Other sections of the AP describe a) definition of the 
terms used in the AAM, ARM, and AIM, b) implementation and conformance test guide lines, and 
c) AP relationship to Units of Functionality. 

Modeling Methodology 

The AAM and ARM were developed using IDEF methodology in order to represent the 
information being conveyed to the reader. IDEF was developed through the Air Force’s Integrated 
Computer Aided Manufacturing Definition Program. The AAM is built using IDEFO which is an 
activity modeling method. The ARM is built using IDEF1X modeling method which is an 
information modeling method. The AIM modeling method was created specifically for this AP and 
is based upon various modeling techniques. The component parts of IDEFO and IDEF1X models are 
shown in figures 2a and 2b respectively. IDEFO models are composed of ICOMs, arrows, and boxes. 
Each activity or f unction is represented by a box which takes in any combination of Inputs, Controls, 
Mechanisms, and Outputs through arrows. Each activity can be decomposed into further activities. 
An entire IDEFO model is a hierarchal representation of a process composed of activities and 
functions. In each sub-level are the activities making up an upper level function. Arrows pass 
information, data, and product between levels as necessary. 

In the 1DEF1X method a piece of information is represented as an entity, a relationship, an 
attribute to an entity, or some type of assertion[3]. The IDEF1X structure is top-down where top 
entities (objects) are composed of bottom entities. Entities are represented by rectangles as shown 
in figure 2b. The syntax for describing relationships between entities is also shown. Entities which 
are beyond the scope of the model have a dashed rectangular outline. These entities are in the mode! 
to complete an open relationship or clarify a relationship. 

Application Activity Model 

An organization intending to implement this AP would look at the AAM to see if their 
information is within scope and within the context needed for planning the necessary automation 
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changes! 1 J. The viewpoint of the model is from that of designers and manufacturers of hybrid 
microcircuit assemblies. The model is meant to be generic, i.e. it is not specific to a particular 
manufacturers operations. Unfortunately, the generality of the model leaves many open issues. For 
example, the model as it stands, applies to MCMs, thick film hybrids, thin film hybrids, etc. The 
fundamental differences between these technologies is not represented in the AAM. The other AP 
models, especially the ARM has facilities for differentiating between various hybrid technology types. 
The AAM shows where the information in the ARM is used. 

Figure 3a and 3b show model diagrams page A-0 and AO. These are the first and second level 
diagrams which present the major activities necessary to produce an HMA. The A-0 shows the basic 
inputs, controls, and mechanisms required to produce the various outputs from a manufacture hybrid 
devices activity. The inputs are physical things such as Supplies & Materials and Industry Technology 
as well as information from Customer Requirements. Controls on the activities are documentation 
like military, industry, and company standards. Controls are usually those things which are not 
changed in any form by the activity they enter into. The outputs are not only Shipped Hybrids but 
also Scrap generated in production process, Prototypes built before production and required to be 
delivered to the customer, and response to the customers request for price quotes. 

The A-0 activity is decomposed into four activities which are the core of an HMA manufacturer’s 
operations. The first activity is the Management Of Customer Orders which uses the Customer 
Requirements from diagram A-0 to generate a Quote Response. The second activity is Performs 
Engineering which uses Industry Technology and Supplies & Materials to produce Prototypes in 
accordance with Standards and Customer Requirements. Data generated from prototype fabrication 
as well as Scrap Information is used to produce various engineering documents. This activity also 
produces drawings, schematics, layouts, released design, etc. The third activity Assure Product 
Quality, takes in drawings and other documents from Perform Engineering and Customer 
Requirements information to produce a quality plan. Production data from Produce Hybrids is 
analyzed using statistical methods and results are fed into Produce Hybrids and Perform Engineering. 
The final activity is the actual production of hybrids. Supplies and Materials are taken in and the 
hybrids along with documentation are produced according to the released design drawings and in 
keeping with standards. Scrap and Production data are also generated. The remainder of the AAM 
in the AP is composed of decompositions of AO activities to various levels. 

The AAM was arrived at by consulting previous AAM models built under Navy contract by 
various HMA manufacturers. Active participants in the building of the AAM were the Navy and two 
major military HMA manufacturers. Agreement of the AAM was received from the US Navy’s 
MicroCIM program Ad-Hoc Advisory Panel, a group composed of government, industry, and 
academia interested in HMAs. 

Application Reference Model 

The ARM describes the hybrid product information. The model presents an enterprise-view of 
information of the hybrid as a product! 1], The ARM is a reference point for implementation of the 
AIM. It shows how various types of product information relate to one another and how a particular 
piece of information fits into the concept of an HMA. The documented information as presented in 
the ARM supports the activities of the AAM. It also provides the baseline for the development of 
the AIM. 

Figure 4 presents the top most diagram of the ARM for HMAs. This page in the model can be 
read as follows (refer to figure 2b): 

The highest Jevel entity in the model is the Hybrid CAD Presentation. This entity has one key 
attribute. The key attribute uniquely identifies every instance of the entity. The other 
attributes are characteristics of a Hybrid CAD Presentation such as; layers of an HMA are 
built on separate CAD Layers. The connection between the entities Hybrid CAD 
Presentation and Hybrid Version can be read: Hybrid CAD Presentation is a CAD design of 
zero, one, or more Hybrid Versions. A Hybrid Version is uniquely identified by an 
attribute called Hybrid ID. The Hybrid Version was designed using zero, one, or many 
Design Rules and a Design Rule is involved during the design of zero, one, or many Hybrid 
Versions. The dotted line between these two entities indicates that they are not dependant 
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upon one another. A Hybrid Version is zero or one Assembly Occurrence and contains zero, 
one, or many Assembly Occurrences. An Assembly Occurrence is uniquely identified by an 
Assembly Occurrence ID, it also has an attribute representing various types. An Assemble 
Occurrence is dependant upon its relationship with Hybrid Version. An Assembly 
Occurrence involves zero, one, or more Process Steps. A Process Step instance is uniquely 
identified by a Process Step No. and has Station, Process Description, and Log Requirements 
as attributes. The Process Step is dependant upon the relationship it has with Assembly 
Occurrence. The remaining entity to entity relationships for Process Step can be read as 
follows. A Process Step is produced using zero, one, or many Tools. A Process Step is used 
in one or more Assembly Consumables. A Process Step utilizes zero, one, or more Patterns. 

A Process Step is followed by zero, one, or many Process Steps. A Process Step has attached 
zero, one, or many Hybrid Assembly Components. A Process Step achieves an assembly 
using zero, one, or more Process Operations. The entities Hybrid Assembly Component, 
Pattern, and Process Step are dependant upon their relationship with Process Step. 

The remainder of the diagram can be read as above. As stated previously, the ARM is the baseline 
from which the AIM is developed. The AIM shows how the information contained in the ARM is 
to be expressed by subsets of IGES entities. 


Application Interpreted Model 

The scope of the AIM is limited to LEP (layered electrical products) information which most 
ECAD systems contain. HMAs are a subset of the wide range of LEP types (ie. MCMs, Printed 
Circuit Boards, etc.). The IGES entities selected for implementation in the AIM were selected so as 
to minimize the total file size. The selected IGES entities have restrictions placed upon their use 
either through the Global, Direct Entry, or Parameter Data sections. This is done so as to restrict the 
number of different ways a particular entity is used within an HMA CAD file. Other IGES entities 
can be used within a file but they should not be used for purposes stated in the AIM[1). Table 2 is 
a subset of the selected IGES entities. The Type and Form headings are IGES numbers set by the 
standard itself. They are listed so that an implementer of the AIM can refer to the standard for 
specific information on the entity. The Status field describes the entities current status. Standard 
means that the entity exists and does not need to be modified to be used in the AIM. Gray means that 
the entity is located in the Gray pages of the current IGES version document. RFC (Request For 
Change) means that the entity is either new or needs to be modified and an RFC exists and is in the 
ballot process. New means that the entity does not exist and an RFC needs to submitted. Modified 
means that an existing entity needs to modified to be used in the AIM. The AIM individual object 
definition entity models contain usage restrictions appropriate to the application. These restrictions 
are described in detail in the AP with the object models. Figures 5a and 5b are two sample object 
models from the AP. 


Table 2 

A Sampling of IGES Entities used in AIM 


Status 

Type 

Form 

Standard 

100 

0 

Standard 

102 

0 

Standard 

106 

63 

Standard 

124 

0-1 

Modified 

125 

All 

Standard 

312 

1 

Modified 

402 

18 

New 

402 

5xxx 

Grey 

406 

27 

New 

406 

5xxx 

RFC 

406 

5xxx 


Description 
Circular Arc 
Composite Curve 
Copious Data 
Transformation Matrix 
Predefined Planar Shape 
Text Display Template 
Flow Associativity 
Net Connectivity Assoc. 
Property- Generic Data 
Property- Region Fill 
Property- Definition Extent 
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The graphic notation developed for the AIM object models is meant to ease the development of 
unambiguous translators conforming to the AIM. The notation is composed of several principle 
elements; Object Definition Block, Object Instance Block, Object Value Block, and Cardinality code. 
The latter three elements are related and derived from the Object Definition Block which designates 
an IGES entity type, form, directory entry value, parameter data values, and relationships to other 
IGES entities. Definitions for the other graphic notations in the AIM can be found in the AP. 

For readability, the diagrams in the AIM are divided into six subsections. Section one contains 
the AIM interface object models. These represent a perspective of an LEP in which one can exchange 
data. The interface object models describe the set of independent entities in a IGES file which are 
part of an LEP. Currently, there exist three interface objects in the AIM; Part Library, Physical 
Layout, and Technical Illustration. 

Section 2 defines objects specific to LEPs. Display Geometry is section 3 and defines objects that 
are common to CAD/CAM systems that use 2D geometry. A miscellaneous section contains 
subordinate objects which are used in combination to form an LEP specific object. There is also a 
section that defines objects referenced from the Direct Entry sections of other objects. In the final 
section are objects that represent pre-defined Direct Entry values. Figure 5a is an example of a 
model from the Interface Section, figure 5b comes form the Display Geometry section. 

INDUSTRY IMPLEMENTATION 

As stated in the introduction it will be up to private industry to implement the AP. Specifically 
it is expected that ECAD system manufacturers such as Mentor Graphics, Intergraph, Cadence, 
Harris, and Computer Vision will implement the AIM in their next generation of translators for 
ECAD systems. To successfully conform to the AP, these vendors must design their ECAD system 
translators to be capable of reading and writing CAD/CAM files that conform to the AIM. The 
designers and manufacturers of HMAs can then use these systems without having to worry about the 
cost and loss in efficiency currently inherent when transferring CAD files between dissimilar ECAD 
systems and sometimes between the same type of system. The U.S. Navy ,by building this AP, has 
served as a catalyst for a solution to the file transfer problem. It is now up to the HMA industry to 
demand the implementation of this solution from ECAD system manufacturers. 

FUTURE DEVELOPMENT 

Conformance requirements and testing applications have not yet been fully developed for the AP. 
It is hoped that industry will take on these tasks as part of a continuing effort to improve this 
Application Protocol for hybrid microcircuit assemblies. 
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CONTROLS 

factors that constrain the activity 


iL 

OUTPUTS 

■^results of the 
activity 


MECHANISMS 

people, tools, equipment that perform or 
support the activity 

Figure 2a: IDEFO Methodology Diagram 


INPUTS 

information, materials, or 
other that is changed within 
the activity. 


ACTIVITY 


Independent Entity Name 


key attribute 

attribute A 
attribute B 


Parent Entity 


(solid line denotes an • 
identifying relationship) 


contains (this verb describes the relationship 
of the parent to the child) 


Dependent Entity Name 


(cardinality: P = one or more) 


f key attribute 

\ 

attribute 


V 

J 


Child Entity 


Figure 2b: IDEF1X Methodology Diagram 
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Figure 3a: AAM diagram A-0, top of model 



Figure 3b: AAM diagram AO 
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tivity 

Desert ption 
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cults a {roup of Package Symbol Instances for the 
explKii purpose of being treated as a group with related 
placement restrictions The Region Restriction property 
worts in conjunction with the Component Placement 
Associativity 

Require me nts/RettrkrtSoru : 

* The L£P Object Type/Sub-Type property which is ref- 
erenced from the Group Associativity object, must 
specify (orype»Component_Placement_Asjociaiiviiy. 
irypr«*) 

5 The first object referenced by the Component Mace 
ment Associativity must be cither a Component Place 
mem Kccptn or a Component Placement Kcepoui 
followed by the Package Symbol Instances which are 
affected by the Componem Placement Associativity 

6 AH objects that are subordinate to the Group Associa- 
tivity, are physically dependent on the same parent as 
the Group Associativity 

Translation Usage Notes: 

General: 

Output: 

Input: 


1 ApoUcauon l«Mcrp*TUXf Model 



mi< <) lul f I IWJ 


Figure 5a: Example object mode! specific to Layered Electrical Products (LEP) 
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Figure 5b: Example object model for Display Geometry 
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